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Executive Summary 

NOTE: This is an executive summary of the overall document (all 3 sections). For convenience, during the 
preliminary definition process it is being repeated in each section. 



This document describes the specifications, functionality and infrastructure of the UMG player. The 
document has three sections each addressing a part of the player and its operation. This document does not 
attempt to provide a fully comprehensive detailed specification of the player or its operation, but rather to 
provide a framework in which the player can be developed. 



The three sections of the document are: 



♦ Section One 

♦ Section Two 

♦ Section Three 



Architecture 

Functions 

Infrastructure 



It is anticipated this document will be used to refine the design and 
development of the player. It is intended that this development itsptf be^ 
following phases: 



Phase One Non functional GUI prototypes 

Phase Two Non functional prototype incluj||glterat< 

Phase Three Partially functional protor^CwimTfeature co; 

Phase Four Feature complete player i Alpha state 

Phase Five Feature complete pre proc^kion player in Beta S^te 

Phase Six Feature complete productift^ayer for Geieral Release 




1 have the 



components 
e GUI and specification 



This section of the document describes th< 
the deployment of the UMP. The documeni 
establishing these as a base for t^gjurther e 
delivery system. 





compori^^^fS systems that will be needed to support 
th those requirements for the anticipated trials and 
id deployment of the player into a commercial 
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Assumptions 

We are considering four possible scenarios which can affect the business and technical infrastructure: 



Scenario 1 - All the objects are pre-packaged into secure containers (DigiBoxes) during the production 

process, prior to distribution. This includes both the "content and rules objects" coming from 
the distributors and "retail rules objects" coming from the retailers. The "content and rules 
objects" and the "retail rules objects" are kept in separate containers. When an order is placed 
based on a retail offer, we take the appropriate retailer's container and the object container(s) it 
controls and send them to the user. Unless there is a "magic" way to bind those containers 
together (which we are investigating), the "retail container** is likely to disappear during 
superdistribution. 



Scenario 2 - All the objects, both the "content and rules objects" coming froi 
rules objects" coming from the retailers, are not contained (i.e 
in storage. When a request comes in, a container (DigiBox 
rules is created "on the fly'*. In this scenario the retailer' 

Scenario 3 - All the objects are pre-packaged into secure com 
process, prior to distribution. Unlike the Seen; 
retailer's) controlling it are placed in the same ^intairfi 
container (DigiBox) including content, ow&ejferiffretail 
retailer's rights will persist in superdisi 



Scenario 4 - A combination of 1 and 2. All the o 
(DigiBoxes) during the production proa 
new, container of multiple DigfeBoxes is cr< 
will persist in superdistributio] 




gtributors ajE& 4t retail 
plaoeMp DigiBom) while 
comity owner Had retail 
tribution. 

e<production 
fes (owner's and 
>mes in, a prepared 
s scenario the 



To reduce the computational loa 
cached. 

Each of the scenarios h^fl 
offs. We will be im^i&eatin] 



accepted, it will n< 





Scenarii 



^aged mto secure containers 
DUtion. When a request comes in, a 
". In this scenario the retailer's rights 



ntainers for the most popular requests can be 



es api involves a number of business and technical trade- 
what is the magnitude of these trade-offs. 



For the purposj^fejthis d^umentv^ass^ed that Scenario 1 is adopted . If a different scenario is 




e architecture. 



xptions in this document which were not brought out here because they 
the assumptions, issues, alternatives, questions, etc., are italicized. 




Some Definitions 

Note: This section will be a separate document and will be moved out of the later versions of this one. This 
section is here to establish some definitions which would be useful in the discussion that follows. 

Container or Digibox (used interchangeably) 



Always contains one or more Control Sets (= Business Rules) governing applicable objects. Usually will 
contain one or more Objects (or Properties). 

Each Container (Digibox) will have a unique identifier - Container ED or CID 
reference, or URL. The Containers "in circulation" which have exactly the s; 
Control Sets) will generally have the same CID, but Containers with differenl 
different CID's. The CID will be in the form of an alpha numeric 
might be in the form of the IEN 128 bar code standard or another si 
may also have a Date/Time stamp and a version number, e.g. /emi 



There will be two types of Containers in the EMD: those that 
usually have Objects in them) and those that are produced 
only. This is based on Scenario 1 of the Assumptions. 



The CID format should be selected carefully to m( 
identify the Container, 2) it should be consistent 
UMG, 3) it should hopefully be descriptive, 4) it s] 
actually type it, and 5) it should be automatically hai 
possible, similar to the way a router will qSndle an 

Note that CID does not provide a detailed 6s 
the container's table of contentekOB&EQC 



Digital Objects or Con] 

Any digital asset 
identify an ob[ 
objects (i.e., tht 
and will have its 
AdditiQJgSillj^me 
Iturn 

EachO 
circulation' 
OID will be 




;ors (they will 
ntain Control Sets 





following goal^^^must allow to uniquely 
the identifications ctllintly in use by the industry and 
'reasonable length so that a person can 
pication with the least intelligence 



the content. Such a description will be provided in 



an album, a song, text, graphics. If it is desirable to uniquely 
an Object ID or ODD. An object can itself consist of multiple 
example, an album consisting of 10 songs is an object in itself 
songs is most likely an object and will also have its own OID. 
video and/or graphics associated with them (to be displayed on the 
own OID's. 



a part of the object's reference, or URL. The identical Objects "in 
have the same OID, but different Objects will always have different OID's. 
of an alpha numeric string with a structured format. 



The 



Some possible goals for the OID format: 1) allow to uniquely identify the Object, 2) be consistent with the 
current/emerging digital media asset identifications, 3) be descriptive, 4) be of reasonable length so that a 
person can actually type it, and 5) it should be automatically handled by the application with the least 
intelligence possible, similar to the way a router will handle an IP address. 

The Composite Object's OID does not consist of the OID's of the objects inside it. Instead, from the 
player's perspective the Composite Object's OID is a server and the OID's of the objects inside it are the 
pages on that server. For example, /emi.phantom.l987.hifid may be the OED of the complete recording of 
"Phantom of the Of>era" made by EMI in 1987 and encoded with high fidelity, while 
/emi. phantom. 1987.hifid/angel_of_music may be the OID of the "Angel of Music" song from that 
recording. These content objects however may not be individually accessible or may require other objects 
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to be played at the same time. This constraint on accessibility will be implemented through the 
EDL/Associations function of the player. The associations will enforce the obligation to always keep 
material together or to keep any relationship the creator implies. 

Alternatively, we can use UniversaTs SKU's as OID's. This is a very simple and short format. Its possible 
drawbacks: 1) it's non-descriptive, and 2) some digital objects we'd like to manage may not have SKU's. 

Objects will have attributes. These will effectively be descriptive fields, thought they may be referenced 
within the association structure to create relationships between objects. The current set of properties fall 
into two categories, creator and owner. The creator set will include the Artist(s), Writer(s),Musicians(s), 
producer(S) and any other material that will assist in both finding the material in a search through the 
player Find function and provide the information for PRO and other mandated righ^^^yKment 
functions. The Owner properties will define the owner of the copyright in both^p^^^^^sher(s), and 
the recording, Music Company(s) as well as the distribution channel (s) if apprgJflytte. This dlipet will be 
used for the management of the rights of the content as well as the use in tl^Playitend functic 
It is anticipated that the actual Audio and Video material will be watern^^mvith s^lkof this i»rmation 
in the form of an ISRC or ISWC code and that the player will likely cji^ek this status t^Mdatejpe content 
and protect the IPR of the owners. 



Channel Identifiers 

The channel identifiers will provide the details of 1 
will include two data sets, the identifier of the Ret 
Distributor (Distributor ID, or DID). These fields 1 
to redirect the reference to the correct site. These 1 
settlement functions. These ID's should be alphanii 
RID = tower.ny (Tower Records, NY sei* 





cula^^duct offerjpame to market. This 
ler ID, orf|||>) and the Identifier of the 
be used as paramel^p^hen the object is referenced 
the parameters in the usage and 
descriptive, e.g., DID = Universal, 



Digital Object Handle 

Digital Object Handle (or 
below are given for illusj 

Suppose the EMD 
Records' websi 
DOH for this 

/tw/rep 

No ! 



represents a request for a product. Examples of handles 



lumber of distributors and a user in LA logs onto Tower 
ttra's ''Everything Happens to Me" by Reprise Records. The 
/OBD/CID/RID, or as an example 

^ns_to_me. 1996.hifid/ tower.sinatra.everything. 123098/tower.la.doh 

s is actually the one from the retailer. 



In another ^^tole, aTBtf gets Sinatra's "Everything Happens to Me" container superdistributed from a 
friend and triesm^iy it. However, the Control Set does not allow purchasing of that particular container. 
Instead, the requtp^ets sent to the EMD with a DOH = /DID/OID/CID: 

/tw/reprise.sinatra.everything_happens_to_me. 1996.hifid/reprise.sinatra.everything. 101798. v. ldoh 
Note that the CID in this example is the one from the distributor. 

What if we use an "SKU approach" to deriving ID's? Possible DOH's from a retailer and from 
superdistribution would look as follows: 

/tw/audio.l234567/tower.6789.99/tower.la.doh 

/tw/ audio. 1234567/tw.987654.doh 
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High-Level Conceptual Architecture 

The architecture should be designed around four main EMD functions: 

manage the digital assets 
securely deliver the content 
find the content 

track usage and provide settlements 



Diagram 1 illustrates the proposed high-level architecture of the EMD service. The architecture consists of 
a number of blocks (components). Each of the architectural components is defined^p^^OT a specific set 
of related functions while communicating with other components through speci^pmterfa^^^nce the 
interfaces are determined, the overall development can be broken down into a^^^kmanageaW^Wallel 
development of individual systems which will be integrated together. Witfa^this cffoall archit^ire the 
individual systems are outlined below. 



$$, Usage 

UMG 
Business 
Systems and 
Processes 

Content, 

Rules 




Diagram 1. High-Level Conceptual Architecture 



Content Production System(s) 



These systems provide processing, labeling and packaging of the content and associated business rules into 
the formats suitable for storage and distribution on the Internet. Content Production will be integrated into 
the existing business processes and systems. Within the EMD the Content Production will interface to the 
Content Delivery System to which it will forward the secured content and business rules (in Digiboxes) 
plus the information for finding the objects. The Content Production System (CPS) will also have an 
interface to the Retail Sites for providing information about the content availability and receiving 
associated retail business rules (which will be contained in DigiBoxes). In the short-term the Content 
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Production System will also interface to the Usage and Settlement Systems (USS)for payments and usage 
information; eventually, the USS interface will be migrated directly into the internal Business Operations 
Support Systems (BOSS). 

Content Delivery System 

This system is central to the architecture as it interfaces with the users and with most other systems of the 
service. It receives and stores secured content and rules from the Content Production System. It also 
receives content requests from the users, resolves these requests and delivers secured content to the users. 
Lastly, in some cases it accesses the Global Directory System to find the content (e.g., to support the 
player's Find function). 

We may consider making users interact with the Global Directory System directly i^m^^Mcft'nj? "Find" 
searches. This would be less objectionable to other distributors. My feeling rigfv^w^W^^e users go 
through the Delivery System, to have the default Content Delivery System set tjgMMG but allo^msers to 
change the default. 

Global Directory System jg' v M 

The Global Directory System enables the Find function of the pjgpfoy Tl^^^tent Del^er^ements will 
be optimized for quickly finding and delivering the content ^^^p n an easytrajgresolvegptandard 
references. The Global Directory System will be designed^pw^^searches^^^^^aifferent indexes. 
The other function of the Global Directory System is tojm^ the lliS, service gfljpfTby providing a 
"bridge" between different distributors. The produ^^r^vdelivery^^^is are likely to be internal to 
distributors (at least those who can afford them). (Jeating a Global Dir^^^Syste 111 which is "open" to 
all the content providers will make the overall EM^ystem more attractivjlx> both users and distributors. 
This system may have to be managed and maintain ^g utside ofEA 



Retail Sites 

This will be the first point of contact with thWisei 
the page containing the refer^g^^^^conte] 
will then be transparent to^^Retail^^^The' 
application to downloacV^fe|er Rights ll|tot 
also interface with th^Cont^^Kroductionwste; 
provide associate* 




y have located a web server and downloaded 
e., m<?ffiRDH). All actions upon select ing this ref erence 
etail Sites will include the links to the |^^^| 

if they have not already done so. The Retail sites will 
to receive information about the content availability and 



ile host, initially the Wintel PC. This is described in detail in Section 
te infrastructure perspective, the player needs to be supplemented with a 



Usage and 



ystems 



These systems poHorm mostiy a clearinghouse function. They will provide the mechanism for the user to 
access the secured content by transacting for the appropriate rights. They will collect information on usage 
and transactions, which may include surveys and other non-financial information sets. The Usage and 
Settlement Systems interface with the users, with retail sites and with the internal business systems of 
content providers. The Usage and Setdement Systems should be coordinated with UMG's business 
systems. However, it must be remembered that in order for the EMD service to be "open" the Usage and 
Settlement Systems should be a "common resource". 

I^^H Application 

Secures the content and business rules by providing encrypted containers; enforces the business rules. 
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Operations and Customer Service 
Operational support for players in the field. 

"External" Communications Infrastructure 

Communications elements outside of our control which impact performance of the EMD service. 
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Content Production System 



The Content Production System (CPS) will fulfill a number of important functions: 



create digital objects for the electronic delivery 
enable identification and tracking of digital content 
enable creation of the retail business rules 
secure the content together with the applicable business rules 
process payments and usage information (in the short term) 
interface with the "traditional" business processes and systems 

It is particularly important to carefully lay out the long- and short-term strategic 
migration path between the two, because the CPS is the system most affected 
operations. The table below illustrates some of the possible differences h 
implementations. 




CPS 



Short-Term Implementation 



Number of CPS's 



One per distribj 




>ssib>yone per label 

IntegrS^^.fKo the overall product 
plan 



Electronic Product Planning 



Asset Management 



Local to < 



! organization 



Across the enterprise 



Payment and Usage Information 



Receffed by CPS 



Interfaces to Other Systems and 
Organizations 



E-mail, letter, 
ctronic 





eceived by business and 
marketing B systems 



Transparent electronic data 
transfer 



Table 1: Some Features of the 



the Long-Term CPS Implementation 



Goals and Requip* 



This is a partial 1 



apabilities that CPS has to meet: 



i different formats (CD, 128 Kbps, 384 Kbps, GIF, ... ) 
fid descriptions for content objects and maintain these associations 
^process, including associations with external (to CPS) objects 
t object into different formats (128 Kbps, 384 Kbps, ... ) 
5n between different digital object formats 
[ store all digital content objects 
^automatically assign unique object ID's 

; objects and query them without user's intervention, automatically extract attributes 
^and create an annotation 
create metadata "proxy" of an object 

arbitrarily group digital objects into any classification hierarchy without duplication 
support user-defined fields 
provide object access and searching capabilities 

easy access via a user-friendly interface, including browsers 

access to object's metadata 

fast retrieval of large objects 

index-based searching 

content-based searching 

attribute-based searching 
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owner- and usage-infromation searching 
track the status of a digital object throughout the production workflow process, provide audit trails 
support user- and group-level security 
provide cross-platform support (Win95, WinNT, MAC, Unix) 
store up to [50,000] objects initially, [1,000,000] objects in the long-term 
provide storage capacity of [4 TB] initially, up to [80 TB] in the long-term 



Current Business Processes and Systems 

Provide high-level Junctional description of the current UMG processes 



Functional Implementation 

The following diagram illustrates suggested high-level funct 
Production System and its interfaces. 




Business 
Processes and 
Systems 



Daigram 2: CPS Functions 



The CPS is divided into five functions: Production, Transaction, Retail, Packing, and Workflow. The 
division is somewhat arbitrary and can be changed to reflect the actual functionality of the development 
and implementation applications, as long as the overall scope of functions remains the same. The 
Production Function is much "larger" than the other four. However, it is anticipated that most of the 




15 



Production Function 



What it does 



This function is responsible for: 

Creating a digital object 

Processing the source content 

Processing content's properties, attributes and business rules 
QA'ing source and digital objects 
Indexing digital objects 

Assigning object ID 

Creating associations and classifications for searching 
Searching objects 
Accessing stored objects 

Internal Interfaces 

Internally, the Production function will have the following i 



Packing Function - 



Retail Function - 



the Production function will 
objects for securing into com 

the Production function will! 
content objects for communi! 
object becomes av*ailable for e 



Workflow Function - the Production func 

content objects for col 
providii^^fe^nation 
disi 

All the internal co 
External Interf; 






Functi<Spne digital content 



to the Retail Fujfetion status of the digital 

ers, namely whether and when the 
pnic distribution. 



brkflow Function status of the digital 
;rnally, for generating work orders and 
)ject becomes available for electronic 



electronically and completely automated. 



e Prodl^^i Functi& wffl interface with the Business Processes and Systems. The 
tion wnnceive jfle content objects in the source format, business rules associated with 
ution of ^^^^ojects (release date, required associations, list prices, fidelities, etc.), and 
of tlSse objects (artists, descriptions, text of songs, internal SKU, graphics, etc.). 
11 provide Business Processes and Systems with access to digital content 



It is anticipated trjat initially at least some portions of this interface will be manual. 
Transaction Function 




What it does 

This function is responsible for collecting payment, usage, feedback, "hits" and other market data from the 
Usage and Settlement System and from the Retail Sites. It is anticipated that this function is placed in the 
CPS temporarily, until it can be migrated to the Business Processes and Systems. 

Internal Interfaces 
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Internally, the Transaction function will have the following interfaces: 

Retail Function - the Transaction function will receive from the Retail Function information about 
usage, hits, comments, etc. collected from the retailers. 

All the internal communication will be implemented electronically and completely automated. 

External Interfaces 

Externally, the Transaction Function will interface with the Business Processes and Systems and with the 
Usage and Settlement Systems. The Transaction Function will receive from the U^^gd Settlement 
Systems the usage and payments information. The Transaction Function will prm^eBS^^^Yocesses 
and Systems with the payment information and the usage and other market daja^aggregated ffixroihe USS 
and the Retail Sites. 

It is anticipated that initially at least some portions of this interface \wg|5e mammal. 
Retail Function 
What it does 

This function is responsible for communicating witJyfifn!cfet§il Sites. i®gill inforfh the retailers of 
content's availability, allow them to create retail "dljects" (i.e., offers wH|||^an be processed into 
containers), keep track of the status of retailers' of^s, and ensure that onljn/alid retailers can access the 
system and only with valid offers. 

Internal Interfaces 



Internally, the Retail function will have the iljlov 



es: 



Production Function - the BPail fti^^^^ill nkeive from the Production Function status of the digital 
c^^^objects f^^^nmi^^ating to the retailers, namely whether and when the 
^jecr^^tomes availble fir electronic distribution. 

Transaction Fu&flpn - th^etaill^^ion^ll send to the Transaction Function information about usage, 
t hi^^mimeni^^^collected from the retailers. 



Packiri^^^n - l^^etail^btion will send to the Packing Function "retail business rules" objects 
forl^^^n in containers. 

All the in^^^^l^^feftion will be implemented electronically and completely automated. 

External Interfac 

Externally, the Retail function will interface with the Retail Sites and the Business Processes and Systems. 

The Retail Function will allow retailers to log on via their browsers, check the information about the 
content available for sale over the Internet and 'Till out" a form creating a "retail business rules" object. 
The Retail Function will also actively "push" out to the retailers information about the new content and 
reminders of the timing of their retail offers (e.g., if an offer will expire soon). 

The Retail Function will receive from Business Processes and Systems information about the Retail Sites 
which can access the system. 
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It is anticipated that initially at least some portions of this interface will be manual. 
Workflow Function 
What it does 

This operational function is responsible for keeping track of the "work-in-progress*' objects and for creating 
"work orders" to "pace" the work. 

Internal Interfaces 

Internally, the Workflow function will have the following interface: 

Production Function - the Workflow function will receive from the Productioa^&ction statu^Mthe digital 
content objects and the associated data (e.g., the source contik has beenll|eived 
and encoded but one of the files required by "busm^rules"^^giations ^missing) 
until the object becomes available for electron^^stributjgn. 

All the internal communication will be implemented electronic^ 

External Interfaces 

Externally, the Workflow function will interface wij(^^&u^iness PfS^^es and Systems and with the 
CPS's personnel. The Workflow Function will communicate to the B usm^^Processes and Systems 
information about the status of the "work-in-progr||s" objects and die itenprremaining to complete the 
work. 



It is anticipated that initially at least some 
Packing Function 
What it does 



tipns of 



Intern; 

InternaM^he 
Production 

Retail Function - 




This function is respo|g;ible Me cons 
content (Audio, ^^^TOraphi^^^) and 
for transferringi^contar 
will be derive 




vill be manual. 



on gi the secure containers, with the inclusion of the actual 
associated business rules as applicable. It is also responsible 



ana^ig^efcgphce data to the Content Delivery System. The Packing Function 
prefer application. 




n will have the following interfaces: 



on - the Packing Function will receive from the Production Function the digital content 
objects prepared for the electronic distribution, including the content and the 
associated business rules. 

the Packing Function will receive from the Retail Function the "retail business rules" 
objects prepared for the electronic distribution. 



All the internal communication will be implemented electronically and completely automated. 
External Interfaces 

Externally, the Retail Function will interface with the Content Delivery System. The Packing Function will 
send to the Content Delivery System secured containers (DigiBoxes) prepared for the Internet distribution, 
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together with the information about the "contained content" for resolving customers' requests and for 
inclusion in the Global Directory (e.g., to support the Find function). 

It is anticipated that this interface will be electronic and completely automated. 



Content Production System Architecture Overview 

The following diagram illustrates a possible CPS system architecture. 





1 1 



III 





To the external systems 





High-speed LAN 





uction System Architecture 



uction Function "front-end", Packing and Workflow Functions. 



manalpis "metadata" storage and access of the Production Function. May not be 
sary in the short-term, while the content database is small. 

manages actual content storage and access of the Production Function. May perform 
the Index Server functions in the short-term, while the content database is small. 

Web Transaction Server - manages Retail and Transaction Functions. 

Proxy Server - provides a secure firewall for the content production. 

Content Database - stores the actual digital objects together with their properties, attributes, descriptions 
and associations. The key index is OID. 

Index Database - stores information about digital objects - their key properties, attributes, descriptions 
and associations. The key index is OLD; highly searchable. 
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Container Database - stores the secure containers (DigiBoxes). Can be searched on both CID and OID 
indexes. 

Retailers Database - stores the retailers information and their "retail offer" objects. Can be searched on 
both RID and OID indexes and other information. 

Administration Database - stores the information about payments, usage and other market data. Can be 
searched on RID, OID, CID and other indexes. 
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Content Delivery System 

This system will provide the services, functions and performance required to support the delivery of the 
content to the consumer. The Content Delivery System (CDS) will fulfill the following functions: 

receive and store secure containers and associated information 
quickly find and retrieve the requested content 

establish communication and transfer the requested content without customer's intervention, 
completely and without errors 

provide customers with alternatives when the requested content is not available 
operate in an on-line environment with up to [50,000] requests/day short-J^^^^p,000] 
requests/day long-term. 



Functional Implementation 

The following diagram illustrates suggested high-level function^^fe^lei^^^^n ot th^CojEUnt Delivery 
System and its interfaces: 






Content Delivery System Functional Diagram 



The CDS is divided into three functions: Reference, Access, and Communication. The division is 
somewhat arbitrary and can be changed to reflect the actual functionality of the development and 
implementation applications, as long as the overall scope of functions remains the same (probably, a more 
granular approach - i.e., a larger number of "smaller" functions - will be needed). 

Reference Function 

What it does 




This function is always the one receiving the customer's request. The request would be either for an object 
defined by its DOH or a "Find" request for search based on certain keywords or object attributes. The 
DOH can be a "handle" from a retailer's site pointing to an offer in the form of /DID/OID/CID/RID, or a 
"handle" in some other form, e.g., an OID typed in by the user (we have to dig in deeper on what kinds of 
u handles" are possible /allowed). 

There is only one Reference Function per distributorship (in the long-term the actual implementation might 
be distributed for faster response). A request would go to the Reference Function of a particular 
distributorship because either 1) the DID in the handle is for that distributorship, or 2) this is a "Find" 
request and the distributorship is the default one for that player. 



The Reference Function is responsible for resolving the request and redirecting it if 
do that the Reference Function keeps track on a distributorship- wide basis of all 
and retail offers) and containers authorized by the distributorship for electronij 
the Reference Function maintains information about all the OID's, CID's 
(associations) and selected relevant information (e.g., the expiration 
content objects, etc.). Because "handles" can remain in circulation loj 
expired, the Reference Function should maintain the information 
expired. 




In order to 
content 
ifically, 
hips 
and 

offer has 



If the DOH request is successfully resolved (i.e., there is QH#^ri^^ly one obje^^ce®bination of objects 
corresponding to this "handle" and this object(s) is avaiM>l^t the B^jbutorshir^^e resolved request is 
forwarded to the Access Function. Note that this isjti^xewhqt differenlm^ the 5/27 version of this 
document, where all the requests had to go througma secure X.500 direc^^^ervice. Here if the request is 
for the object(s) from the same distributorship as tnkReference Function, prcan stay within the 
distributorship's network where the communicationWan be securea%y other (besides the X.500 service) 
means. This assumes that either there is^asingle AccWjkFunction pmr distributorship, or the Reference 
Function knows which Access Function ^^^£- The 1^^^^^^^0tction has an option to go through the 
X.500 directory for all requests, and some^^M^^a^stributors^nay choose to implement it this way. 




If the DOH request can not b^s^^^^lly reefed beSpSTe, for example, this particular offer has expired 
but there are objects or co^TOnation^^^^cts wiich can be substituted for this "handle" and these 
object(s) are available at^^^^stributors^^the l||perence Function will offer to the customer a menu of 
suggestions. Busin^^ales^^eating tlS||p suggestions will have to be defined, e.g., first offer(s) for the 
same content obj^^OID) fromf||e same rHiiler (RID), then offer(s) for the same content object (OID) 
from other sourg||f (e.g., dther ret^^g^orj^ distributor itself). If the same OID can't be found in the 
Reference Funct^^kday^s^, the Rl|yence Function will forward the request to the Global Directory 
Service Kyggif the^^^object can befound elsewhere. If it is found, the customer will be offered it. If 
not, tW^^we Fun^^gi wiU offer to the customer to conduct a more detailed search (it is assumed that 
the J^fl&rencelpnction wrl^^^OTer to substitute a different object (OID)). 

If the requ^Msn^^^^fitf^ operation, the Reference Function will redirect it to the Global Directory 
System. Altewmtiyely, the Reference Function may first try to search within the distributorship, by passing 
the request to itsW^ess Function, This preferential treatment may, however, have a negative effect on 
other distributors/? independents joining the service (a good example is the airline reservations industry 
where multiple systems ended up competing, each favoring some of the airlines). 

There are a number of possible implementations of how the Reference Function will interact with the 
Global Directory Service (GDS): 



1) Once the Reference Function redirects the request to the GDS, the customer establishes a session 
directly with the GDS and the Reference Function is not involved. When the customer finds the 
object he/she wants, the GDS will redirect the customer to (needs to be resolved) either a) the 
Reference Function of the distributor of the object, orb) the Access Function controlling the 
object ( which may or may not be UMG's), or 
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2) The Reference Function queries the GDS in the background, Le., from the customer's perspective 
he/she is still interacting with the same Reference Function, When the customer finds the object 
he/she wants, the Reference Function will redirect the customer to the Access Function controlling 
the object. If the Access Function is not UMG's, the redirection will be via the GDS. 

In the following discussion we assumed that Approach 2 is used. 

Internal Interfaces 

Internally, the Reference Function will have the following interface: 

Access Function - the Reference Function will send to the Access Function the 
request. The request will include the OID, CID and RID 
data (e.g., TCP/IP address). Which of these ID's are ne± 
redundant depends on how the objects are stored ( inxontci 
containers formed ( in advance or on-the-fly). De$0amg on 
are addressed, the Reference Function may alsj 
Function and/or the Access Function may pt 
Function's database (if there are multipl^emjess 
if the GDS is bypassed in intra-distrib^^hip request 

All the internal communication will be implemented elej^f^cally^^^completef^utomated. 

External Interfaces 

Externally, the Reference Function will interface wllguhe customer^ UMP, with the Global Directory 
System and with the Content ProductionJSystem. A^^cribed ab<we, from the UMP the Reference 
Function will receive content requests. T^^^eference^^^^M^^l send queries to the GDS based on the 
"Find" requests and unresolved requests. ^^^^^^S thei^^rence Function will receive the "reference 
data" which will include all the OID's, CE)\an^^^te|^^ilable for electronic distribution from this 
distributor ( as discussed a ^°^^^^^^^ molmmuin onefl&ccess Function per distributorship, the ' 
"reference data " may hav^mcome^^^he A&sess Functions). 




It is anticipated that 
automated 

Access Function 

Whati 



Thisfu 
Content 
on many di 
the Global Diri 




will be implemented electronically and completely 




onsible Jsr storing, tracking and accessing the objects/containers received from the 
It keeps detailed information about the available content (allowing searches 
indexes and keywords) and supplies this information (probably in a summary form) to 
ystem (GDS). 



The primary operational activity of the Access Function is to receive a request for content from the 
Reference Function, determine where the content is physically available and pass the transfer request to the 
Communication Function. The exact division of responsibilities between the Access Function and the 
Communication Function will need to be discussed, particularly in the area managing the performance - 
scheduling transmission, balancing loads, selecting the optimum location for downloading. For the sake of 
argument we will assume that these responsibilities reside in the Communication Function and that the 
Access Function will determine where the content is available and will send the content's ID's and 
locations to the Communication Function. 
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We assume that there will be only one Access Function per distributor, albeit existing in multiple instances. 
If this is not correct (e.g., each label implements its own Access Function), it will affect how the Reference 
Function obtains its "reference data". 

Internal Interfaces 



Internally, the Access function will have the following interfaces: 



Reference Function ■ 



the Access Function will receive from the Reference Function the resolved content 
request The request will include the OID, CID and RID information, plus the user 
data (e.g., TCP/IP address). 



All the internal communication will be implemenl 



External Interfaces 

Externally, the Access Function will int< 
Production System. The Access Functioi 
objects being controlled by the Access Fi 
condensed version of the object's properties 
producer, writer, publisher, ctofll^^kdate 
function. The retailers infg^ation^^ot be 
on how some of the assy 
redirected from "othei£ RefeS 





Communication Function - the Access function will send to the Communication K^flctioS^lr^^ta transfer 
request, consisting of the ED's of the data to be transferr^^he locauons8|here the 
data is stored and the user's address. The exact natuneof # %t |P needealm the 
Communication Function will depend on how therigfects arewmed and pmeessed 
into containers. If as assumed here, the °bjecm&e placed intoammloac^le 
containers in the CPS, the Access Function^^a^^^omm^cate^^^p(s) only. 
If on the other hand, CDS needs to form ^^^/te^m^^the ob%ctsffrior to 
downloading, the Communication Funj0m will contarm& "Packgm Function" and 
the OID's will be communicated. 



automated. 



|ory System and with the Content 
aation" to the GDS about the content 
^formation" will include OID plus a 
;.g., title, artists, musicians, composer, 
fidelity, keywords, etc.) to assist the Find 
deluded in the GDS. The Access Function may (depending 
receive content requests and queries from the GDS 



From the CPSj^Accessl 
include all the OllgkCI 
"directory informatic 



1 r^dfive the containers or objects and the associated data which will 
ailable for electronic distribution from this distributor plus all the 



gjSal communication will be implemented electronically and completely 



What it does 



This function is responsible for managing all the downloading of content from the CDS to the consumers. 
In interacting with a customer, the Communication Function has to be able to download large objects while 
guaranteeing completeness and freedom from errors (i.e., after the download the object at the UMP should 
be exactly the same as the object at the CDS) even over an unreliable communications path. It should be 
user-friendly, e.g., require no user intervention while providing useful information, such as storage required 
and time left. It should be able to multitask with other resources on the UMP's platform. 

The other critical aspect of the Communication Function is its ability to handle multiple simultaneous 
requests. It should be able to optimize / balance the load across multiple servers and datastores. However, 
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this by itself won't be enough. It is anticipated that in the EMD service a small portion of the content will 
generate most of the demand, and that "hits" or promotions will create temporary but very significant 
"spikes" in user requests. A system capable of handling such input "spikes" without some way of 
"smoothing" the output is likely to be prohibitively expensive or even impossible (due to reliance on the 
"external" telecommunications infrastructure). The Communication Function should be intelligent enough 
to deal with such situations via scheduling and multicasting. The multicasting capability will exploit the 
fact that the demand "spikes" will most likely be caused by requests for the same content. Instead of 
sending the file to each customer individually, the file can be multicast to a group of customers. For the 
multicasting to be effective, it would require a sophisticated scheduling mechanism to form these 
multicasting groups in real time. Scheduling mechanism can further ease the load by offering downloads 
during off-peak hours (e.g., in the middle of the night). The performance can be further improved by a 
distributed architecture where the content is stored in multiple places so that it can bedashed" to the end 
users from a local server. This in turn requires sophisticated content replication ^ysyncn^i^ation 
techniques. 



Most likely all of the above measures will be needed for deploying the 
scale. Thus, the Communication Function will be a complex one, n 
sophisticated interaction of traditional communications protocols, 
multicasting and database replication. 

Internal Interfaces 

Internally, the Communication Function will have I 



Access Function - 




mass 



the Communication Fimctioiwill receive from the Recess Function the content 
transfer request. The reques^Ml include theta>'s of the data to be transferred, the 
locations where thgdata is stonS|ajid the useSs address. The exact nature of the 
ID's needed by ^^M^^wnicara^fe^^^^wi// depend on how the objects are 
stored and processeahni^^m^iners^e^he discussion above). 



All the internal communicati^^^^bg^imple] 

External Interfaces 

Externally, the O 
Communicatiq 
completeness ani 



It is 
aut< 





eleeironically and completely automated. 



only interface with the customer via the UMP. The 
ansfer session, download the container(s) and verify 



Communication will be implemented electronically and completely 



Content Ddliyery System Architecture Overview 

The following diagram illustrates a possible CDS system architecture. 
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Global Directory Services 





Diagram 5 - Possible Content Delivery System Architecture * 

It consists of the following elements: 



Reference Server 



Index Server 



manages the Referem 
eventualW^ave multi] 
requesj^^^feiards 





One per distributor, although is likely to 

mprove customer service. Resolves customer 
dex Server or the Global Directory Service. 



Content 



rranuiM the "fronMhd" oHe Access Function. May also host the "front end" of 
i Co^^micationMnction (e.g., scheduling and load balancing). Keeps track of 
ere the^gbent is Jpored, all the related ID' s, properties, attributes, "directory 
aation^lyk^tes storage for the content being received from the CPS. 

nterPrequests from the Reference Server and translates them into the 

i for the Content Servers. Updates GDS. Assumed one per 
Ithough is likely to eventually have multiple instances to improve 
custdlllPservice. 

^rSBage the "back-end" of the Access Function (actual content storage and retrieval) 
and the Communication Function (except that scheduling and load balancing may be 
centralized at the Index Server). If the containers are formed "on-the-fly" (rather 
than prepared in advance), performs the Packing Function (see CPS). Highly 
distributed. In each instance is a "server farm" interconnected with a very high- 
speed local network. 



Content Database - stores the actual containers or digital objects, depending on what's received from the 
CPS. The key index is either CID or OLD. Highly distributed. 

Index Database - stores information about digital objects - their key properties, attributes, descriptions 
and associations. The key index is OID; highly searchable. Assumed one per 
distributor, although is likely to eventually have multiple instances to improve 
customer service. 
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Reference Database - stores information necessary to resolve DOH's, mainly OID, CID and RID. One per 
distributor, although is likely to eventually have multiple instances to improve 
customer service 



Communication Links - high-speed dedicated connections to the Internet from the Reference Server and 
the Content Servers; high-speed on-demand connections for the private network 
interconnecting the servers, CPS and GDS (as shown) or a virtual private network 
over the Internet - if security, reliability and throughput concerns can be addressed. 
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Global Directory System 



The Global Directory System (GDS) will serve a dual purpose: 

1) to support the "Find" function in the UMP, and 

2) to provide the interconnection point between Content Delivery Systems of different distributors 
compatible with the EMD service. 

The "interconnection" concept is illustrated in the following diagram. 




Diagram 6 

The analogy is 
interconnect^ 
access to the conteiJ 
service^Kifes to 
bec^mEMD^mpatibl 
the uK^^cjuiMgd customei 
be quite e 



temUs an Industry Interconnection Point 

iere npQltiple service providers can connect at one of the defined 

provide a single secure directory services function, such that all 
jstijlutor's "private network" is undertaken through this transparent 
a motivation on the part of other distributors and independents to 
maintain their own production and delivery and still have access to all 
they can outsource their production and/or delivery functions (which can 
ent) to UMG but maintain their brand before the customers. 




Given that the Kj||yB defined as an industry-wide resource, it probably best be maintained by an industry 
organization, sucp^s IFPL If the consensus on GDS is not achieved in a reasonable time-frame, UMG's 
service launch won't be delayed - the "Find" function will be enabled in the Index Server of the Content 
Delivery System, which has all the information needed (however, the searches will be limited to the UMG 
material and those partners who chose to either include their information in the UMG's Index Database or 
to connect their Index Server to UMG's Reference Server). 



It is envisioned that the GDS database will eventually have a reference to every digital content object 
available for electronic distribution in the EMD-compatible format. This reference should include a unique 
OID, the appropriate Index Server and at least those properties and attributes which are most likely to be 
used in a "Find" function search. Except for the Index Server, these information is created during the 
production process. Given that the standards for digital objects' identification are not well developed, it is 
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important to review the work of relevant organizations and vendors to ensure that EMD's formats are 
compatible with whatever de juro or de facto standards emerge. 



Global Directory System Architecture Overview 

The following diagram illustrates a possible CDS system architecture. 






Reference Sexver-2 
is requesting your 
object OID 





Diagram 7: Possi 

The envisaged approj 
act as a gateway 
content is ston 
reference servl 
translate the requesf 
objectj^^^^aid to 
usei 





^ectoiar Service Architecture 

ectory services model. The X500 directory server system will 
s and the content databases and server farms where the 
rs). The X500 system will only transact with legitimate 
content for supported connections. The X500 server will 
server into an instruction for the index server which "owns" the 
er and, eventually, for the correct database to send the content to the 



Recomme 



Solution 
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Usage and Settlement Systems 



Consist of Finance Clearing House, Information Clearing House, and the Deployment Manager. 

The Finance Clearing House (FCH) will manage payment processing when purchasing occurs. When a 
customer wants to access the content within a Digibox, he/she will transact with the FCH to obtain the 
appropriate rights. FCH will have gateways to banks and credit card processors to handle various forms of 
payment. FCH should be able to aggregate multiple transactions into a single one. FCH has to maintain 
extensive audit records. 



The deployment manager will provide the user with the with whig 

transactions with the FCH and gain access to the content. This may become a : 
X500 gateway with a separate server for this purpose, or may be a free standi^ 

The Information Clearing House will collect usage and survey info; 
reporting services. 

In the long-term both FCH and ICH will have to be integrate^ 
Support Systems (BOSS). 



:rtake the 
the 



fessOperations 
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Retail Sites 

Basically a web server. Once accepted into the EMD, becomes a part of UMG's extranet. Needs an 
application to log onto the Web Transaction Server of the Content Production System, to fill out a form 
creating a "retail business rules" object and incorporate the appropriate DOH's into its pages. May 
eventually be allowed to do the packing internally. 
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Application 
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Support Functions 



■ UMP Applications 

■ Customer Support 

H Development Support 



Application support 

Elements needed for player deployment and support of the delivery of mi 
spans the processes and supporting systems and infrastructure to ensur^f&t 
consumer in the manner intended 

The player has a number if functions that require support. 

Content (Digibox) delivery 
Content referencing 
Buddy list servers 
Content related sites (band sites) 



Mail Proxy 

A standard Mail proxy server set up to sup] 
for contact with the artist, produ^esdl&bel or 




Chat- Buddy G^wa 

This will be a 
gateway to anothe] 
undertafe^ditional 
the A|pxor 

In addii 





area 



igailj addresses included in the Digibox' s as content 
omoflllSl purposes. 



rt a chat service contained within the Digibox or provide a 
tant Message. This gateway may include CGI type scripts to 
received to match the current obligations and requirements of 



here "live" Artist interaction will be channeled through. 



This will also|^vide access to the simultaneous play functions to be offered to the users and as such may 
support a numbeipPscripts and functions to support multiple users playing a particular piece of Artist 
material. This mafy involve the use of streaming and multicasting. 



Domain Servers 

The Domain servers will provide the prime addressing for the content. This is likely to be in the form of 
Domain.newmusic/content/artist/label. This will be the location of the web pages identified within the 
Digboxes. 
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Operational Support 



In addition there will need to be systems to support the players operation in the field. This will initially 
involve the users and trial members but will expand to support users, developers and potentially other 
content providers. 

This will also include the support of some of the financial transactions and their implications 



Customer Support 

After the player is deployed there are significant need for a customer support 



Dispute resolution 
Back and Restore 
Product support 
Customer service 




volve 
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Infrastructure Deployment Plan 



Pilot 

■ Functionality to be tested 

■ Sizing 

■ Implementation 



Trial Size estimates 
50 albums at release 

■ Limited Commercial Rollout 

■ Functionality to be tested 

■ Sizing 

■ Implementation 

■ Full Commercial Rollout 

■ Sizing 

■ Implementation 




Use Scenarios 



Main Scenaios 

■ New Content Offer 

■ Retailer Changes Business Rules 

■ Content Provider Changes Business Rules 

■ User Downloads UMP Client 

■ User Downloads Content 

■ User Purchases Content 

■ Superdistribution 

■ Settlement 

Secondary Scenarios and Exception Handling 
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